Peter Trommler [Thu, 11 Jun 2020 06:31:22 +0000 (08:31 +0200)]
[PATCH] FFI: Fix pass small ints in foreign call wrappers
The Haskell calling convention requires integer parameters smaller
than wordsize to be promoted to wordsize (where the upper bits are
don't care). To access such small integer parameter read a word from
the parameter array and then cast that word to the small integer
target type.
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
[ Ilias Tsitsimpis ]
* Correctly set 'haddock-interfaces' for base libraries (Closes: #968446)
* Remove files generated by postinst script (Closes: #909922)
* Add myself as an uploader
[ Gianfranco Costamagna ]
* Lower parallel builds to 2 on Ubuntu armhf, to speed up build process.
[ Adrian Bunk ]
* Update to llvm-11. (Closes: #974794)
Peter Trommler [Thu, 11 Jun 2020 06:31:22 +0000 (08:31 +0200)]
[PATCH] FFI: Fix pass small ints in foreign call wrappers
The Haskell calling convention requires integer parameters smaller
than wordsize to be promoted to wordsize (where the upper bits are
don't care). To access such small integer parameter read a word from
the parameter array and then cast that word to the small integer
target type.
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
Ilias Tsitsimpis [Tue, 11 Aug 2020 14:12:43 +0000 (15:12 +0100)]
ghc (8.8.4-1) unstable; urgency=medium
* New upstream release
* Fix gen_contents_index to use ghc-pkg to parse the package database
(Closes: #966069)
* Use locally-installed MathJax.js when generating library docs
(Closes: #890627)
* Patch Haddock to remove hard-coded googleapis font URL (Closes: #963690)
* Backport upstream patch to fix FFI on unregisterised big endian machines
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:
$ ./configure --target=powerpc-unknown-linux-gnu && make
...
SCCs aren't in reverse dependent order
bad blockId n3U
This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.
The change adds the `cmp_lo` label into the case of negative
comparison. Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
.
Origin: https://gitlab.haskell.org/ghc/ghc/commit/25dce3fc05e4788240ac6d192919063a9f548f7f
Last-Update: 2019-08-09
When two 32-bit floats are adjacent for a 64-bit target, there is no
padding between them to force alignment, so we must combine their bit
representations into a single word.
Commit 4075656e8bb introduced a regression stopping existing unregisteristed
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `rts/storage/ClosureTypes.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/15913.
.
This patch can be removed, once ghc-8.4 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/15913
Bug-Debian: https://bugs.debian.org/932941
Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:
```
if (at == NULL) {
*len -= *len / 8;
```
and caused assertion failure:
```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
(GHC version 8.7.20180716 for riscv64_unknown_linux)
```
The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'
Trac #15338 is yet another example where -Bsymbolic breaks
semantics of a C program: global variable duplication happens
and unsafePerformIO creates two stdout copies.
When -Bsymbolic is not used both C compiler and linker agree
on how global variables are handled. In case of sh4 it consists
on a few assertions:
1. global variable is exported from shared library
2. code is referred to this variable via GOT-like mechanism to allow
interposition
3. global variable is present .bss section on an executable
(as an R_*_COPY relocation: symbol contents is copied at executable
startup time)
4. and symbol in executable interposes symbol in shared library.
This way both code in shared library and code in executable refer
to a copy of global variable in .bss section of an executable.
Unfortunately -Bsymbolic option breaks assumption [2.] and generates
direct references to the symbol. This causes mismatch between
values seen from executable and values seen from shared library code.
This change disables '-Bsymbolic' for unregisterised targets.
Gbp-Pq: Name bsymbolic-only-for-registerised.patch
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
$ ./configure --target=powerpc-unknown-linux-gnu && make
...
SCCs aren't in reverse dependent order
bad blockId n3U
This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.
The change adds the `cmp_lo` label into the case of negative
comparison. Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
.
Origin: https://gitlab.haskell.org/ghc/ghc/commit/25dce3fc05e4788240ac6d192919063a9f548f7f
Last-Update: 2019-08-09
When two 32-bit floats are adjacent for a 64-bit target, there is no
padding between them to force alignment, so we must combine their bit
representations into a single word.
.
error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/15913.
.
This patch can be removed, once ghc-8.4 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/15913
Bug-Debian: https://bugs.debian.org/932941
Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:
```
if (at == NULL) {
*len -= *len / 8;
```
and caused assertion failure:
```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
(GHC version 8.7.20180716 for riscv64_unknown_linux)
```
The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'
[ John Paul Adrian Glaubitz ]
* Enable workaround to avoid memory exhaustation on alpha
[ Gianfranco Costamagna ]
* Source-only reupload now that the bootstrap has ended
projects / ghc.git / log